1. Technical Field
The present invention relates to a method for exchanging media description information between user agents using a session initiation protocol (SIP) and, more particularly, to a method for exchanging media description information between the user agents using an SIP, which enables an operating system (OS) and a kind of sound module that the user agent uses to be indicated in an additional information field of a session description protocol (SDP) including information on the session, so that voice communication between the user agents using different sound modules can be smoothly conducted.
2. Related Art
It has been well known that SIP is a signal protocol establishing and releasing a session in a single network that is a standard for VoIP phones for locating and connecting user agents in a multipoint audio-graphic conference. As is the case with hypertext transfer protocol (HTTP), SIP is a versatile and convenient protocol. SIP supports both collaboration multimedia conference and voice service electronic commerce. An Internet engineering task force (IETF) announced RFC 2543 as the first version of SIP, and most recently made RFC 3261 public in June 2002.
SIP is an ideal protocol for VoIP in which traditional end-to-end voice lines in a legacy network can be replaced with a session on the Internet. Such a function exists not only in the ITU H.323 multimedia standard, but also in the private VoIP phones of some companies. Some companies who had manufactured products before the entrance of SIP had adopted H.323. However, SIP is a protocol which is transferable more simply, and which is smaller and lighter in its overhead, than H.323.
Since SIP renders existing telephone connections closer to a standard, it is easier to conduct advanced service, such as a presence. This makes it possible to immediately check whether users can receive a call from a video or instant messaging session as well as a specific telephone, and users want to receive the call. Also, it can forward a call to multiple destinations in VoIP calling.
Although SIP can use transmission control protocol (TCP), in addition to a user datagram protocol (UDP), as a transmission means, SIP uses UDP at port 5060 as a default value. If an SIP packet is lost by an unreliable protocol such as UDP, SIP firstly determines whether to wait for a sufficient time, and then retransmits an instruction. ‘INVITE’ is the most general instruction that SIP sends to another end point. An SIP phone sends the ‘INVITE’ instruction when a user agent tries to connect with another SIP phone or user agent. If the invitation is accepted, a response of ‘200’ is returned to the originator who generated and sent the invitation message, which means everything is all right and a session has been established.
With the request for ‘INVITE’, SDP informs the user agent of the caller's media capabilities. If a called group answers, an ‘OK’ message is sent in reply, and this message includes the media capabilities supported.
Although some SIP phones can call each other directly, if an extension capability is required, a server is required. An SIP server continuously traces directory information and the location of a called group. There are several SIP servers, each of which can be operated as the same server or on its own hardware platform.
The SIP servers include a proxy server for generating a request and establishing a connection as a substitute for the user agent, a redirect server for providing the user agent with replaced location information in response to the request but not participating in the connecting creation, a registration server for use in a present location registration by means of SIP equipment such as telephones, and a location server for storing location information in a database and resident in a physical server, such as a general registration server.
The SIP proxy server processes the request of SIP phones or a user agent. The proxy server initiates the connection with regard to a recipient instead of an originator, and is resident in a loop until a response of ‘200’ (an ‘OK’ message) is received. Since the proxy server has its IP address in a ‘Via’ field, a destination client can know where the response should be sent. The proxy server then sends the response to the originator in turn. An address of a ‘Contact’ field is used for direct communication between user agents.
If the proxy server transmits an ‘INVITE’ request, it immediately sends back a status message of ‘100’ or ‘trying’. This is a message informing the originator of the operation that the ‘INVITE’ request has been sent. The proxy server determines the location of a destination user agent, sends the user agent an ‘INVITE’ message, and then sends the originator a ‘180’ or ‘ringing’ message. The recipient sends the proxy server a ‘200’ response while answering it, and the proxy server sends a message to the original user agent.
The originator who receives the ‘200’ message sends the destination client an ‘ACK’ response so as to inform the client of the fact that the originator has received the ‘200’ message. All communications thereafter are conducted between the clients, and a real-time transport protocol (RTP) takes responsibility for digitized audio transport between the user agents. Once the call is completed, a ‘BYE’ message is transported to another user agent, which in turn sends another ‘200’ response.
Although, upon the completion of the call, the proxy server basically frees itself from the loop, it may be constructed so as to be in the periphery of the loop. The method thereof is that, when the proxy server communicates with the user agent, it inserts its own address in a ‘Contact’ field so as to enable the user agent to send back a response to the proxy server instead of the originating user agent. Maintaining the involvement of a proxy while calling makes it possible to render a detailed report at a point where a trace for calling time is possible. This also impedes, for the purpose of security, the details of the network end point.
The redirect server receives the request from the user agent or the proxy server. The redirect server cannot make a connection by itself, but merely responds with information as to where the original request should be retried. The method of using the redirect server may be one which is capable of giving the user agent required information quickly and without putting a heavy burden on the proxy server.
If the proxy server is in use, the register server is required. For example, when the telecommuter connects a VoIP phone, this equipment becomes an opposite party's location in the register server. As long as there is an SIP gateway which is usable upon connection of a call, many telephones can be registered in the register server.
Until now, the SIP has been seen schematically. The SIP does not transport digital speech, and the transportation thereof is under the RTP's charge. The RTP transports voice communication after the SIP establishes a call. If the SIP were able to establish voice, text messaging or video sessions using various codecs and technologies, it would first have to determine which function is supported by equipment in the sessions. In this case, the session description protocol (SDP) intervenes and the SIP negotiates the use of the SDP to provide conversation between two endpoints.
The SDP is used for recording additional information concerning the session in SIP, and aims at interworking with various transport protocols (service advertising protocol (SAP), SIP and real-time streaming protocol (RTSP)). SDP transports media stream information of the corresponding session in order to allow the recipient receiving the session description to participate in the session.
The SDP includes session name, session activation time, media constituting session, information receiving the media, bandwidth information used by conference, and contact information of a person in charge of the session.
The SDP body is composed of the three fields of session description, time description and media description, each of which is constructed as an item such as in Table 1, Table 2 and Table 3 below. Table 1 illustrates session description, Table 2 illustrates time description and Table 3 illustrates media description.
TABLE 1Session DescriptionvProtocol versionoOwner/creator and session identifiersSession nameiSession informationuURI of descriptioneEmail addresspPhone numbercCorrection information-notrequired if included in all mediabBandwidth informationzTime zone adjustmentskEncryption keyaZero or more session attribute lines
TABLE 2Time DescriptiontTime the session is activerZero or more repeat times
TABLE 3Media DescriptionmMedia name and transport addressiMedia titlecConnection information-optionalif included at session levelbBandwidth informationkEncryption keyaZero or more media attribute linesdDetailed information